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REMARKS 

Reconsideration of the rejections set forth in the Office Action is respectfully requested. 
By this amendment claim 10 has been amended. Currently, claims 1-10 and 15-22 are pending 
in this application. 

Rejection under 35 USC 1 12 . first paragraph 

The Examiner rejected claims 10, 15, and 17 under 35 USC 112, first paragraph, as 
failing to comply with the written description requirement. Specifically, the Examiner stated that 
the claimed subject matter "each of the fields including a number of bits smaller than a total 
number of bits of the destination MAC address" is not described in the specification. This 
rejection is respectfully traversed in view of the following arguments. 

This application relates to a way to allow a switch to directly identify the output port for a 
given frame without performing a table access operation. (Specification at Paragraph 18). 
Specifically, applicants discovered that it would be advantageous to provide a frame with frame 
contained destination information that would allow one or more switches on the network to 
receive the frame, look at the destination information and output the frame on a correct port to 
that destination without requiring the switch to perform a table lookup. 

One of the ways that applicants proposed to do this, was to use the portion of the header 
normally used as the destination MAC address to contain source routing information that would 
specify a particular path through the switches on the local network. In this embodiment, rather 
than look at the whole destination MAC address (DA) and perform a FIB lookup based on the 
DA, the switches would look at a particular field within the DA and switch based on that content 
of that field. 

This is described extensively within the application, but the Examiner's attention is 
particularly directed to paragraph 26. In Paragraph 26, applicants explain that Fig. 3 shows a 
destination MAC address that may be used in connection with one embodiment. Applicants then 
explain, that in that embodiment the local MAC address has a first field containing 18 bits, a 
second field containing 14 bits, and a third field containing 8 bits. These three fields add up to 
40 bits of the 48 bits of a standard Ethernet DA. Applicants mentioned in paragraph 24 that the 
length of a standard MAC address is 6 bytes or 48 bit Thus, these paragraphs clearly show a 
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MAC address having a length, and several fields, each of which have fewer bits than the entire 
MAC address. 

Claim 10 recites "a destination Media Access Control (MAC) address, the destination 
MAC address being a local MAC address having a plurality of fields, each of the fields including 
a number of bits smaller than a total number of bits of the destination MAC address." 
Paragraphs 24 and 26 of the specification teaches this concept. Namely, paragraph 24 teaches 
that the destination MAC address has a length of 48 bits, and paragraph 26 teaches that the DA 
may be broken into a number of fields having 1 8, 14, and 8 bits respectively. This clearly shows 
that each of the fields has a number of bits that is smaller than the total number of bits of the 
destination MAC address. 

These same arguments likewise apply to claims 15 and 17. Accordingly, applicants 
respectfully submit that the specification as originally presented provided support for the subject 
matter claimed in claims 10, 15, and 17. Accordingly, applicants respectfully request that the 
rejection under 35 USC 112, first paragraph, be withdrawn. 

Rejection under 35 USC 101 

Claim 10 was rejected under 35 USC 101 as being directed to non-statutory subject 
matter. Specifically, the Examiner has taken the position that a protocol data unit is a data 
structure, which is not capable of causing any functional change in the computer and thus does 
not produce a useful result. Claim 10 recites that the data structure comprises a plurality of 
fields, "each of the fields containing a code to be used b v a switch on a network to identify an 
output port on the switch without performing a table lookup operation." (emphasis added). This 
is the recitation of an useful result. Specifically, the data structure contains information that 
allows the switch to identify an output port. Thus, claim 1 0 recites a functional change in. the 
computer and, accordingly, is statutory. 

To clarify this, applicants have amended claim 10 to further recite that the code is used 
by the switch "to enable the switch on the network to make a forwarding decision for the 
protocol data unit." This further specifies how the fields of the protocol data unit enable a 
functional change in the computer and accordingly further support applicant's position that claim 
10 recites statutory subject matter. 
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Rejection under 35 T TSP. 1 07. and 35 USC 103 

Claims 1, 3 f 5, 6, and 10 were rejected under 35 USC 102(e) as anticipated by Schaub 
(U.S. Patent No. 7,190,695). This rejection is respectfully traversed in view of the following 
arguments. 

Schaub addresses how packets in an incoming packet stream may be distributed to 
multiple parallel slower streams for processing within a network element. This is commonly 
referred to as link aggregation. In link aggregation, an aggregation function is related to taking 
packets from multiple slower links and putting the packets onto a faster link. In the reverse 
direction, a distribution function is used to take packets off a higher bandwidth link and 
distribute the packets to the lower bandwidth links, (see Schaub at Col. 1, line 62 to Col. 2, line 
6). 

Schaub explains that there are different types of packet flows, some of which contain 
packets that may be processed out of order and others of which contain packets that must be 
processed in-order. (Schaub at Col. 2, lines 10-17). Schaub proposes to classify packets prior to 
distributing the packets, so that "in-order" packets are sent to the same lower bandwidth link for 
processing within the network element while other packets are distributed among the lower 
bandwidth links in a round-robin fashion to perform load balancing between the available links. 
(Schaub at Col. 3, lines 33-41). 

The categorization is used by the distributor to forward the packet to one of the several 
processing paths within the switch/router. For example, in Fig. 3 of Schaub, a 10 GB Ethernet 
stream is received by a PHY 310, and then passed to a packet distributor 312. The packet 
distributor splits the packet stream into ten 1GB Ethernet streams which are then individually 
processed by 1GB MAC 314 and 1 GB packet processors 316. After processing, the packets are 
sent to a switch fabric 318. 

The Examiner indicated that Schaub taught "making a switching decision... to determine 
an output port from the first switch over which the frame should be forwarded onto the 
communication network" citing Col. 7, lines 47-62 and Col. 9, lines 21-41. Both of these 
sections relate to the distributor making classification decision to forward the packet from the 
packet distributor to one of the internal processors (314, 316), which is unrelated to making a 
switching decision to determine an output port from the first switch over which the frame should 
be forwarded onto the communication network. Note, for example, in Fig. 3 the packets are sent 
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from the packet distributor to the processors 314, 316, and then to the switch fabric 318. The 
distributor is not making a switching decision that relates to selecting an output port, but rather is 
selecting an internal processing channel for the packets. 

Fig. 5 of Schaub is identified as a "packet distributor." (Col 7, lines 23-25). At Col 7, 
lines 47-62, Schaub teaches that packets which are to be provided to the packet categorier 530 
are first passed to a parser 540 which looks at fields of interest such as the MAC addresses, IP 
addresses, etc. This does not mean that the packet distributor is making decisions related to the 
output port from the first switch, however. Rather, the packet distributor is making a decision as 
to how the packets should be handled within the network element - i.e. which parallel path 
within the network element should be used to process the packets before forwarding the packets 
to the switch fabric. Each packet processor then makes forwarding decisions for the packets that 
are assigned to it by performing a standard FIB lookup. (See Schaub at Col. 5, lines 42-51 - 
MACs 314 read the layer 2 headers and perform layer 2 look-ups to determine how to forward 
the incoming packets../'). Thus, this portion of Schaub teaches distributing packets within the 
switch, so that different portions of the incoming packet stream may be processed by different 
MAC processors. Each of the MAC processors then performs a standard FIB lookup to forward 
the packet. Thus, this portion of Schaub does not teach or suggest the claimed feature of 
"making a switching decision within the first switch based on the extracted frame contained 
destination information without performing a lookup in a forwarding table to determine an 
output port from the first switch over which the frame should be forwarded onto the 
communication network" as claimed, 

The Examiner al$o cited Col. 9 7 lines 21-41. Tn this portion of Schaub, Schaub teaches 
that the load balancing unit distributes packets among multiple output links. This section of 
Schaub, like the first cited section, relates to how the packet distributor 512 should divide an 
input high bandwidth stream of packets to multiple lower bandwidth processing streams within 
the switch/router and is not addressing how a switching decision should be made to "determine 
an output port from the first switch over which the frame should be forwarded onto the 
communication network" as claimed. Accordingly, this portion of Schaub also does not teach or 
suggest this aspect of claim 1 . Accordingly, applicants respectfully submit that Schaub does not 
anticipate claim 1, and respectfully request that the rejection under 35 USC 102 be withdrawn. 
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In connection with Claim 10 ? the Examiner indicated that Schaub taught a protocol data 
unit data structure having a destination MAC address having a plurality of fields, citing Col. 7, 
lines 47-56. Schaub does not teach or suggest a destination MAC address that has a plurality of 
fields which are individually relevant. Rather, Schaub teaches a standard MAC address. The 
processor 1 10B obtains a HASH from a header of a received packet and uses this HASH plus a 
destination address to determine how to handle the packet. This is not the same as looking into 
the MAC address for a particular field within the MAC address and forwarding based on the 
content of that particular field. Accordingly, applicants also submit that independent claim 10 is 
not anticipated by Schaub. 

Re jection under 35 USC 102 over Pierce 

Claims 15, 16, and 19 were rejected under 35 USC 102(e) as anticipated by Pearce (U.S. 
Patent No. 6,556,574). This rejection is respectfully traversed in view of the following 
arguments. 

Claim 15 recites a method of assigning a Media Access Control (MAC) address to an 
interface on a network, comprising the step of "assigning a first value to a first field of the MAC 
address, the first field containing a smaller number of bits than a total number of bits of the 
destination MAC address, said first value containing first output interface information usable by 
a first switch to identify a first output interface for transmission of frames containing the first 
value in the first field of said MAC address." Pearce does not teach that a field within the DA 
with a smaller number of bits than the DA should have significance. 

In connection with this rejection, the Examiner cited Fig. 6A, element 604. Element 604 
of Fig. 6A shows the first byte of a standard MAC address. As shown in Fig. 6A, the first byte 
of a MAC DA contains a bit 602 indicating whether the address is an individual or group address 
(i.e. multicast designation) and a second bit indicating whether the DA is a local or universal 
MAC DA. These bits are also shown in the MAC address format of Fig. 3 of the specification of 
this application. 

Although these fields do contain a smaller number of bits than the entire DA, they do not 
contain a first value containing first output interface information that is usable by the first switch 
to identify a first output interface as claimed. 
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In connection with this last clement, the Examiner cited Col. 20, lines 10-18. This 
portion of Peace relates to Fig. 10, which is a detailed view of an ARP table 10,000 maintained 
. by a router 130. (Pearce at Col. 19, lines 65-67). The ARP table contains the MAC address 902 
and Routing Information Field (RIF) information 904 for each End Station Port (ESP) route. As 
shown in Fig. 3, the Routing Information Field (RIF) information is contained in the header as a 
separate field 308 from the destination MAC address. 

At Col. 20, lines 10-19, Pearce explains that an end station may have separately 
addressable ports which have different MAC addresses. This does not mean that Pearce is 
proposing to assign different values to different fields of the MAC address as claimed in claim 
15. Rather, this portion of Pearce explains how rows of the ARP table may contain a binding 
between MAC addresses and end station ports, as well as the Routing Information Field 
information for the route to the end station port. Accordingly, applicants respectfully submit that 
Pearce does not anticipate claim 15 of this application. 

Conclusion 

Applicants respectfully submit that this application is in condition for allowance and an 
action to this effect is respectfully requested. If there are any questions or concerns regarding the 
amendments or these remarks, the Examiner is requested to telephone the undersigned at the 
telephone number listed below. 

If any fees are due in connection with this filing, the Commissioner is hereby authorized 
to charge payment of the fees associated with this communication or credit any overpayment to 
Deposit Account No. 502246 (Ref: NN-14715). 

Respsetfully Submitted 



Dated: May 1 . 2008 



John C Gorecki. Esq. 
P.O. Box 553 
Carlisle, MA 01741 
Tel: (978) 371-3218 
Fax: (978) 371-3219 
john@gorecki.us 




JohjrC Gorecki 
SgistrationNo. 38,471 
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